The Context API introduced in React version 16.3.0 is used to manage a global state that needs to be accessed by multiple components in a React application. Context provides a way to pass data through the component tree without having to pass props down manually at every level. In a typical React application, data is passed top-down (parent to child) via props, but such usage can be cumbersome for certain types of props (e.g. locale preference, UI theme) that are required by many components within an application. Context provides a way to share values like these between components without having to explicitly pass a prop through every level of the tree.
The nearest common ancestor could be far removed from the components that need data, and lifting state up that high can lead to a situation called “prop drilling”. Context api solves that.
Context lets the parent component make some information available to any component in the tree below it—no matter how deep—without passing it explicitly through props.
We have a small component tree that needs to share the current theme (light or dark). How would you set that up using React Context?
If you forget to wrap a subtree with the Provider, what will happen when a child calls useContext for that value?
You added a Context to provide user preferences, but the UI is re‑rendering every time any unrelated part of the state changes. How would you diagnose and fix the performance issue?
During a feature rollout, the team split the Provider into two separate files and the app started throwing "Context not found" errors in some routes. What could cause that and how would you resolve it?
Our application has several nested Providers (auth, theme, locale). How would you structure them to minimize render overhead and keep the codebase maintainable?
We need to expose a Context value that is derived from an async API call and should be cached across the app. Describe how you would implement this, handling loading, error states, and avoiding stale data.
The company is migrating a legacy codebase that heavily uses prop drilling to a Context‑based architecture. What migration plan would you propose to ensure a smooth transition and minimal regression risk?
At scale, multiple teams need to share global configuration via Context, but some values are frequently updated while others are static. How would you design the Context hierarchy and update strategy to balance performance, type safety, and cross‑team ownership?